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Abstract 


In the Fall of 2011, National Aeronautics and Space Administra- 
tion (NASA) Glenn Research Center (GRC) participated in the Desert 
Research and Technology Studies (DRATS) field experiments held near 
Flagstaff, Arizona. The objective of the DRATS outing is to provide 
analog mission testing of candidate technologies for space exploration, 
especially those technologies applicable to human exploration of extra- 
terrestrial rocky bodies. These activities are performed at locations with 
similarities to extra-terrestrial conditions. 

This report describes the Extravehicular Activity (EVA) Dual-Band 
Radio Communication System which was demonstrated during the 2011 
outing. The EVA radio system is designed to transport both voice and 
telemetry data through a mobile ad hoc wireless network and employs a 
dual-band radio configuration. Some key characteristics of this system 
include: 1. Dual-band radio configuration. 2. Intelligent switching be- 
tween two different capability wireless networks. 3. Self-healing network. 
4. Simultaneous data and voice communication. 
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1 Executive Summary 

In the Fall of 2011, INASAIlGRCI participated in the Desert Research 
and Technology Studies (jDRATSI) field experiments held near Flagstaff, 
Arizona. The objective of the lDR ATSI outing is to provide analog mission 
testing of candidate technologies for space exploration, especially those 
technologies applicable to human exploration of extra-terrestrial rocky 
bodies. These activities are performed at locations with similarities to 
extra-terrestrial conditions. 

This report describes the Extravehicular Activity (IEVAD Dual-Band 
Radio Communication System which was demonstrated during the 2011 
outing. The lEVAl radio system is designed to transport both voice and 
telemetry data through a mobile ad hoc wireless network and employs a 
dual-band radio configuration. Some key characteristics of this system 
include: 

• Dual-band radio configuration. One 2.4 GHz radio is used for 
high data rate communication and a 900 MHz radio is used for con- 
tingencies to provide improved coverage and extended operational 
range. 

• Intelligent switching between two different capability wire- 
less networks. The switching algorithm utilizes the probability of 
a successful packet transfer (expected transmission count) for the 
wireless links in order to select the appropriate wireless network. 

• Self-healing network. Alternative data paths are determined 
either within the same network, or by transitioning to an alterna- 
tive independent wireless network with different capabilities and 
characteristics. 

• Simultaneous data and voice communication. The wireless 
communication system uses Media Access Control fIMACjl layer 
traffic control and open source Speex-based Voice over Internet 
Protocol (I VoIP I) technology. 

2 Introduction 

Due to the often conflicting requirements of high data rates and reli- 
able radio coverage, a dual-band radio architecture is proposed for future 
IEVAI suit systems. This system uses a wideband, high data rate Radio 
Frequency (1RFD interface with enough throughput to handle simultane- 
ous voice, telemetry, and video flows, as well as a lower data rate RF 
interface that can carry mission essential voice and telemetry. The wide- 
band interface is used amongst all radios while they are in range of each 
other, and since the link range of wideband networks is relatively short, 
the low-rate interface is used when the wideband interface fails. Low- 
priority data flows originating from the suit are queued up locally on 
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Figure 1. Test subjects with EVA Radio backpacks at DRATS 2011. 


the suit and transmitted when the wideband network is available. This 
concept allows for each of the two interfaces to be designed separately 
according to each set of requirements for both coverage and high data 
rates. 

In order for a dual-band radio system to work reliably, the switching 
between the two interfaces must be done gracefully to avoid dropouts 
and loss of data. This is not a trivial problem, as it involves an accurate 
assessment of the wideband link quality at all times. When the radio 
perceives that the wideband link is about to fail, it must propagate 
this information throughout the network so that all other radios can 
switch over to the low-rate interface before any data loss can occur. 
All of the nodes in the mesh must utilize the same network to avoid 
asymmetries in throughput and to ensure all of the nodes are receiving 
the same information. When the network is using the low-rate interface, 
all radios must evaluate the link quality for each wideband link within 
the network. Once all of the wideband links are established and stable, 
the radio network then switches back to using the wideband interface. 

The lEVAl Radio prototypes tested at IDRATSl 2011 (Figured]), are 
designed to implement the features described above using Commercial 
Off-The-Shelf (ICOTSI) radio interfaces and open-source networking soft- 
ware. The system consists of three backpacks replicating lEVAI suits. with 
two being for crew members and the third as a backup. An additional 
base station node simulates a stationary relay communications terminal 
to an earth-based ground station. The IDRATSl test scenarios adhere to 
a typical IEVAI sortie featuring two crew members venturing away from 
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a base station. The objectives of these tests are to: 


• Evaluate the performance of the IRFI interface switching logic 

• Gather the crew members’ feedback about the concept of a dual- 
band radio and the current implementation 

• Evaluate the performance of the IGOTSI radios in an environment 
that more closely matches a lunar /Near-Earth Asteroid (1NEAD set- 
ting 

• Evaluate the performance of the open-source routing software 


3 Radio Testbed 


3.1 Hardware Description 

In order to demonstrate the concept of a dual-band switching radio 
system, a testbed was constructed. The testbed consists of two mobile 
nodes representing EVA crew members and a fixed-node base station 
connected to a ground station terminal, hereafter referred to as XCOMM. 
The two mobile nodes and the single fixed node are constructed with 
the same functional hardware components and utilize the same software 
builds. 

The components of the nodes are primarily ICOTSl hardware, which 
includes an i686-based General Purpose Processor (IGPPjl . a 900 MHz 
Orthogonal Frequency-Division Multiplexing (jOFDMI) radio, a 2.4 GHz 
Wireless Fidelity (|Wi-Fil) radio, an Internet Protocol (1IPI) video camera, 
a pair of speakers, a microphone, and a Global Positioning System 1GPSI) 
receiver. A functional sketch of the dual-band radio testbed is depicted 
in Figure El The IGPPI runs the entire networking stack, handles the 
interfaces for all of the other hardware components and processes all in- 
coming and outgoing data. An i686-based IGPPI is chosen specifically to 
run a full Debian Linux distribution. Linux is used to aid in rapid proto- 
typing by leveraging the inherent software and hardware driver support 
that comes with using an established operating system. An outdoor, 
Access Point (jAPD -class 900 MHz IOFDMI radio is selected as the contin- 
gency interface because of the favorable propagation characteristics and 
the fact that it can be configured for high bandwidth at lower data rates, 
which improves coverage by minimizing inter-symbol interference. The 
2.4 GHz IWi-Fil radio is selected to evaluate the performance of 802.11 in 
an EVA sortie scenario, as well as the fact that an 802.1 I n IAPI is un- 


der consideration for the International Space Station (IISSD 1 1 1 Both the 
900 MHz and 2.4 GHz radios are equipped with dipole antennas. 


1 The USSl External Wireless System described in Boeing’s draft document pj pro- 
poses two ICOTSl Bel Air 802.11n lAPl i to be installed inside the llSSI with the antennas 
mounted outside. Coverage would be available to payloads mounted at several of the 
Express Logistics Carrier sites. 


N ASA/TM— 20 1 2-2 17635 


7 



Figure 2. EVA Node Functional Diagram 


Data is generated by the nodes via lVoIPl voice. video. IGPSl telemetry, 
and network/radio messaging. Each node contains a push-to-talk micro- 
phone connected to a line-level audio input on the IGPPl Audio data is 
encoded, packetized and transmitted over the active IR FI interface. In- 
coming audio is decoded and output to a pair of speakers mounted near 
the crew member’s head. The IIPI video camera, mounted over the shoul- 
der of the crew member, generates an [IP] packet stream of video data 
over a gigabit Ethernet interface to the lGPPl which then routes the video 
data to XCOMM if the IWi-Fll interface is available. If only the 900 MHz 
interface is available, the video data is stored locally until the IWi-Fil in- 
terface is re-established. The IGPSl unit, connected via serial port to the 
IGPPl generates position information once per second. The location is 
transmitted over the active IF FI interface back to XCOMM. The routing 
protocol, described in further detail in Section 13.3.11 also generates its 
own network traffic for the purpose of evaluating link quality and es- 
tablishing routing tables. Finally, the radios themselves generate IMACI 
messages that are used to establish and maintain the wireless networks. 

All of the hardware components are fixed to a plastic backing plate, 
and for the mobile nodes, the plate is securely mounted to a rigid external- 
frame backpack via aluminum struts. Plastic masts for the radio anten- 
nas are also fixed to the plate so that the antennas can be mounted 
safely above the crew member’s head. Figure [3] shows the constructed 
dual-band radio testbed hardware. 
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(a) EVA Base Station 


(b) EVA Testbed Backpack 


Figure 3. EVA Testbed Nodes 


3.2 Radio Configuration 

Both 900 MHz and 2.4 GHz COTS radios used in the IEVAI radio 
system are 802.11-based, although the system profiles are quite different. 
The configuration of each radio is described in the following sections. 

3.2.1 2.4 GHz Wi-Fi Radio Configuration 

The high data-rate radio is configured as an 802.11b/g radio. Refer 
to Table |T] for a summary of the configuration settings. The radio is 
configured in ad hoc mode, as the system is intended to operate in an 
environment where there is no pre-established infrastructure. Request 
To Send (1RTSI) /Clear To Send (1CTSI) is enabled to mitigate the effects 
of the classic hidden node problem, which was deliberately tested during 
the outing. IRTSI / fCTSl is an optional handshaking protocol that ensures a 
receiver is ready to receive a data frame before it is transmitted. A frag- 
mentation threshold is also used so that large file transfers (i.e., stored 
video) will not occupy the wireless channel for long periods of time, 
preventing time-sensitive date from being transmitted during periods of 
high congestion. All data frames that are larger than the fragmentation 
threshold will be fragmented into smaller frames before transmission. 
This is desirable in certain networks, since radios on the network must 
wait for relatively long periods of time while large data frames are being 
transmitted. A fragmentation threshold also improves performance in 
the presence of IRFI interference. The 802.11 channel/frequency is chosen 
to minimize interference with other transmitters observed in the spec- 
trum, as identified during initial test site location evaluation. 
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Configuration 

Setting 

Mode 

ad hoc 

Transmit Power 

30 dBm (1W) 

Frequency 

2.412 GHz 
(802.11 Channel 1) 

Bandwidth 

20 MHz 

Modulation 

variable 

Data Rate 

variable, 1-54 Mbps 
(802.11 b/g) 

Fragmentation Threshold 

512 Bytes 

IBTS|ICTSI 

enabled 


Table 1. Wideband Radio Configuration Settings 


3.2.2 900 MHz Contingency Radio Configuration 

Since the main design objective of the contingency radio is reliable 
coverage, the radio’s 802.11 system profile is configured as such. It is 
important to note here that this radio is not a true 802.11 radio, since 
it operates outside of the 2.4 GHz Industrial, Science and Medical (|ISM|) 
band. The manufacturer intended this radio to be as close as possible 
to an 802.11 radio operating in the 900 MHz IISMI band. To maximize 
range and minimize the Bit Error Rate (IBERI) . Binary Phase Shift Key- 
ing (1BPSKI) modulation is used. High data rates are not needed for 
this interface, so the use of a higher order modulation scheme is unnec- 
essary. To further mitigate the effects of multipath and inter-symbol 
interference, IOFDMI is used with a 20 MHz bandwidth. Since the signal 
is spread out over a large bandwidth, it is less susceptible to narrowband 
fading. Configuration settings for the contingency radio are summarized 
in Table [2j 


Configuration 

Setting 

Mode 

ad hoc 

Transmit Power 

30 dBm 

Frequency 

915 MHz 

Bandwidth 

20 MHz 

Modulation 

BPSK w/ OFDM 

Data Rate 

6 Mbps 

Fragmentation Threshold 

512 Bytes 

IRTFMCTSI 

disabled 


Table 2. 900 MHz Contingency Radio Configuration Settings 
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3.3 Software Implementation 

Where possible, existing software projects are utilized and the devel- 
opment effort made extensive use of open source software. For newly- 
developed software, each core software capability is contained as a sep- 
arate software program or library. The core software capabilities for the 
IEVAI radio system fall into the following primary functional categories: 

• Wireless Mesh Routing 

• Wireless Network Health Sensing and Network Switching 

• Speech Acquisition/Encoding for IVoIPl 

• Sensor Acquisition and Distribution (Telemetry) 

Each core software capability is described in the upcoming sections. All 
of the system software are developed and deployed on the testbed using 
a version control system. Additional information on the software devel- 
opment methodology and the software version control system is found in 
Appendix lAl 

3.3.1 Wireless Mesh Routing 

The IWi-Fil radio hardware is configured to operate in an ad hoc 
mode as opposed to a traditional infrastructure mode. An ad hoc wire- 
less network handles changes in the network topology in a distributed 
fashion, as there is no central IAPI or pre-established infrastructure. The 
ad hoc mode is primarily designed for peer-to-peer communication and 
the network topology must be discovered by each of the nodes. Often 
a peer-to-peer network is used to allow communication between nodes 
which are within range of each other without the need for an IAPI An 
ad hoc wireless mesh network may also implement a routing protocol 
which utilizes other nodes in the network to route and forward data. If 
the destination node is not within direct range of the source node, the 
data is relayed over other members within the network. A disadvantage 
of such a network topology is that the data transmissions are susceptible 
to potentially large network delays. The user does not necessarily have 
control over the path that data takes to reach the intended destination. 
As a result, the information may not route through the most optimal or 
efficient path to the end point. In order to intelligently manage the rout- 
ing of data throughout the wireless mesh on the IWi-Fil network, the IEVAI 
radio system adopted the Optimal Link State Routing (IOLSRI) ad hoc 
wireless mesh routing protocol [2j. Specifically, the open source IOLSRI 
implementation from olsr.org was utilized 0, 0. 

The use of IOLSR I in the network also allows a node to establish a 
communication link to hidden nodes or to nodes which are unable to 
maintain a reliable direct path connection. All members in the wire- 
less mesh may communicate either via a direct link or a multi-hop route 
depending on the optimal path as determined by IOLSRI In order to 
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determine the network routes, IOLSRI sends out HELLO and Topology 
Control (usd messages at regular fixed intervals. These messages deter- 
mine the network topology and distribute the information to all of the 
network nodes. Specifically, the HELLO messages are used to identify the 
neighbors visible to a node and the quality of the corresponding link. The 
iTCl messages are used to distribute the complete topology information to 
the entire mesh. The interval of these control messages is important, as 
the system must properly capture the mesh topology without consum- 
ing potentially limited bandwidth with redundant or unnecessary traffic. 
The default settings for IOLSRI is intended for large wireless mesh net- 
works with nodes that are typically fixed in location. In the I EVA I radio 
system. IOLSR I is applied to a dynamic wireless mesh with mobile nodes. 
The complete system is comprised of only a few nodes, with only one 
stationary member. Therefore, for the IEVAI radio system, the default 
values for the HELLO and [TC] packet interval and corresponding validity 
times are reduced. While this results in a more frequent transmission 
of packets, it allows for the network routing and health metrics to be 
more rapidly determined for the system, which is necessary to properly 
react to the system dynamics. In the IEVAI radio system, the motion of 
a walking human presents changes in the system. The network packets 
used to determine mesh metrics must be generated more frequently than 
topology changes resulting from human motion. As a result, a modest 
value of 0.5 sec or 2 Hz for the HELLO packets is selected, as test results 
indicated walking speeds on the order of 2 m/s. 

The essential IOLSRI configuration settings for the IEVAI radio system 
are found in Table 0 Further information on the IOLSR I configuration 
parameters can be found in the olsrd.conf manual page [5]. Note that 
the table lists the IOLSRI configuration for both the wideband and the 
low data-rate networks. Although IOLSRI is not required for routing 
data on the narrowband wireless network, the software protocol was 
used for analysis purposes to characterize the health of the network, as 
will be further discussed in Section 13.3.21 The implementation of IOLSRI 
on each network for the IEVAI radio system is independent and is not 
intended to allow packet routing between the two networks. The use 
of IOLSRI further provides an added redundancy, allowing for multi-hop 
data routing through the low data-rate network if direct connectivity is 
lost from the base station. 

3.3.2 Wireless Network Health Sensing & Network Switching 

A core component of the IEVAI radio system is the capability to per- 
form intelligent switching between two different wireless networks to 
reach the same destination node. If one wireless network is not avail- 
able or exhibits a poor link quality, an alternative network will be used 
entirely by the system. In order to perform the intelligent switching, 
information pertaining to the health of each wireless network must be 
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OLSR Configuration 

Setting 

Hello Interval 


Wideband: 

0.5 sec 

Narrowband: 

2.0 sec 

Hello Validity Time 


Wideband: 

5.0 sec 

Narrowband: 

20.0 sec 

|T0| Interval 

5.0 sec 

Topology Validity Time 

300.0 sec 

|TC| Redundancy 

All Neighbors 

Link Quality Level 

lETXl enabled 

Link Hysteresis 

disabled 


Table 3. EVA Radio OLSR Configuration Settings 


known to the switching algorithm. To generate the necessary wireless 
link quality information, the IEVAI radio extracts information collected 
by the lOLSRl software. The particular version of IQLSRl implemented by 
the IEVAI radio system utilizes the link quality extension enhancement 
described by De Couto El. 0- The original RFC-compliant IQLSRl pro- 
tocol controls the ad hoc mesh routing by minimizing the total number 
of hops between the source and destination nodes. One issue with the 
simple hop-minimization scheme is that a single direct link with a poor 
health may actually be preferred over a two-hop link with perfect link 
quality. The enhancement to lOLSRl proposed by De Couto overcomes 
this limitation and optimally routes network traffic through the wireless 
mesh by utilizing the Expected Transmission Count (IETXI) metric. The 
IETXI metric is the “expected total number of packet transmissions (in- 
cluding retransmissions) required to successfully deliver a packet along 
that path” [6j. In mathematical terms, the IETXI value is one over the 
probability of a successful data transmission along the path. Therefore, 
the IETXI metric indicates the quality of the connection between two 
nodes in a wireless network. The IQLSRl protocol utilizes this link qual- 
ity information for optimally routing packets in the mesh. Furthermore, 
the IQLSRl protocol also provides distribution of the network topology to 
all of the nodes. 

At each node the network topology and the corresponding quality of 
the link is known. Therefore, the IETXI information can be further ex- 
ploited to provide “sensor” input information to the intelligent network- 
switching algorithm. By knowing the probability of a successful trans- 
mission across the entire network, the primary network used for data 
distribution may be switched. For the IEVAI radio testbed, the network 
link switching is performed using a custom algorithm, with a hysteresis- 
based limit line, as shown in Figure Q] As the highest quality IWi-Fil link 
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Figure 4. EVA Radio Switch Points 


metric to any of the required destination nodes in the network degrades 
below a pre-set value, the switching algorithm triggers a switch to the 
low data-rate network. Since lOLSE I distributes the topology and health 
metrics throughout the mesh, all of the nodes sense the degradation and 
perform the switch. 

The switching parameters for the IEVAI radio system are setup to 
allow degradation of the network health to a level where a multi-hop 
situation will occur on the IWi-Fil network before a switch to the lower 
bandwidth network. When IQLSRI routes data across the mobile ad hoc 
IWi-Fil network, either a direct link or a multi-hop connection may be 
used. In the IEVAI radio system, multiple hops across the various IWi-Fil 
nodes often provides a higher throughput than utilizing the alternative 
low data-rate link. Although the Ultra High Frequency (IUHFI) link has 
a higher probability of maintaining the data flow, it is not adequate at 
delivering the required bandwidth. In the IEVAI radio system, the high 
data-rate video data is not transmitted when the system is operating on 
the low data-rate link. The video data is buffered and re-transmitted 
when the high data-rate network becomes available. Maintaining the 
IWi-Fil network link is therefore more desirable than allowing the system 
to switch to the low data-rate network. When a higher quality direct-link 
connection on the IWi-Fil network becomes available, the IQLSRl protocol 
will automatically update the routes to transition from the multi-hop 
route to the direct link. This allows the system to maintain the data 
flow on the IWi-Fil network as long as possible before switching to the 
low data-rate network. 

OLSR is fully capable of utilizing mixed bandwidth links compris- 
ing one complete wireless mesh. The IETXI metric will result in IQLSRI 
automatically preferring routes with the most efficient data transfer char- 
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acteristics. As a result, one could utilize lOLSRI to route data across both 
the low data-rate and IWi-Fll network interfaces. Yet, allowing IOLSRI to 
fully handle the switching between the low data-rate and the [WTFi] net- 
work is not desirable for the IEVAI radio system. By allowing IOLSRI to 
manage both the IIJHFI and the IWi-Fil links as one contiguous network, 
the setup would allow a low data-rate link to be utilized as a portion of 
the multi-hop route. This potentially allows high bandwidth data to be 
sent over a much lower bandwidth network link, resulting in a bottleneck 
for critical data that must be received in near real-time. In the lEVAl ra- 
dio system, one would rather utilize a store and forward approach for 
the non-critical data and provide high priority or sole usage of the low 
bandwidth communications link for voice and mission critical data com- 
ponents. As a result, for the lEVAl radio testbed. IOLSRI was not allowed 
to span the two different networks. The IOLSRI open source code was 
slightly modified to allow multiple instances of the software daemon to 
run concurrently and independently on the same host. 

3.3.3 Speech Acquisition & Encoding 

For voice transmissions, the lEVAl radio system utilizes IVoIPI technol- 
ogy. Although analog and non llPI digital voice radio systems are com- 
monly used in practice, the use of IVoIPI technology is becoming more 
frequent. Digital voice transmission via IVoIPI offers a number of appeal- 
ing advantages. For example, a digital IVoIPI audio system shares the 
same network as all of the other data flows, eliminating the need for 
a separate network and/or wireless channel devoted strictly to audio. 
Compared to a purely analog system, a wireless IVoIPI system may also 
provide a better quality audio signal with increased clarity during peri- 
ods of signal fading or marginal reception. By utilizing a digital encoded 
speech format, the audio signal is less susceptible to noise on the wireless 
channel, since phase and magnitude distortions cannot directly affect the 
audio. A disadvantage of digital voice systems is the sensitivity to net- 
work latency and jitter. Voice packets can be delayed on a congested 
network or even dropped. IVoIPI protocols have built-in mechanisms for 
handling these issues, but the parameters of these mechanisms often need 
to be optimized for a specific network to maximize the performance of 
the system. These parameters are discussed in detail in this section. 

For the IEVAI radio testbed, the audio data is acquired from a push- 
to-talk microphone on each node and then digitally encoded using Speex. 
The Speex-encoded voice stream is encapsulated into a Real-time Trans- 
port Protocol (IRTPD audio packet stream and then transmitted over the 
wireless network. Speex is an open source/free software patent-free au- 
dio compression format specifically designed for speech [8]. The open 
source aspect of the audio codec eliminated the need to acquire soft- 
ware licenses and therefore expedited software development. Speex is 
also available in a floating point and fixed-point version |2j , although the 
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Speex Configuration 

Setting 

IVADI 

enabled 

IDTXI 

enabled 

IAECI 

disabled 

Sampling Rate 

8 kHz, 20ms/frame 
(Narrowband Mode) 

Jitter Buffer Size 

8 Speex Frames 

Table 4. EVA Radio Speex 

Configuration Settings 


fixed-point implementation was not necessary for the initial I EVA I radio 
proof of concept implementation. Speex is also well-suited for wireless 
applications, as the signal is purposely degraded to reduce the required 
bandwidth. A lossy format as such is quite appropriate for audio content 
containing normal conversational speech. In addition, Speex provides the 
capability to reduce the amount of data transmitted over the network 
based on the audio being encoded. For example, Speex may be config- 
ured to operate in a Voice Activity Detection (1VADI) mode. The IVADI 
mode is used to detect when the audio to be encoded contains actual 
speech content or is merely background noise/silence [9] . The detected 
non-speech periods may then be encoded with the minimal number of 
bits required to generate a comfort noise. Alternatively, a Discontinu- 
ous Transmission ( IDTXI) mode for Speex may be enabled to eliminate 
the comfort noise completely. The IDTXI mode is an enhancement to 
the IVADI mode, where the encoded audio is not transmitted during pe- 
riods of non-speech detection |9j. In IDTXI mode, the IRTPl audio stream 
is maintained, yet only the minimum Ethernet packet size (46 bytes) is 
transmitted. Utilization of the Speex IVADI and IDTXI mode reduces the 
total amount of network traffic for each node and thus allows for a more 
efficient utilization of the wireless link. In the IEVAI radio testbed, the 
IDTXI and IVADI modes are enabled. A number of other configuration 
options are available for the Speex codec. Table 2] provides a summary 
of the Speex configuration options used for the IEVAI radio system. 

A jitter buffer is used on the receiving end of a IVoIPI system to han- 
dle the variation in the IRTPl packet arrival times due to network delays. 
A trade-off must be made between the acceptable latency of the audio 
stream and the desired quality. Increasing the jitter buffer size results 
in an improvement of the audio quality, but is made at the expense 
of an increased latency of the audio stream. For real time operations, 
voice data that is significantly delayed is considered unsatisfactory to 
end users. The International Telecommunications Sector addresses the 
acceptable delays for voice applications. The International Telecommu- 
nication Union (IITUI) recommended one-way delay should not exceed 
400 ms and indicates that callers usually notice round-trip voice delays 
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of 250 ms or more [10]. For IVoIPl applications . a delay requirement of less 
than 200 ms is typical HD. The Speex library provides a jitter buffer, 
which is specifically designed for Speex. The Speex jitter buffer provides 
an adaptive trade-off between good quality audio stream and low latency 
by varying the size of the jitter buffer. If a large network delay is en- 
countered in the system, then the Speex adaptive jitter buffer size will 
be increased to ensure good quality. The issue arises when streaming 
IRTPI packets across a wireless link, where the signal may often fade in 
and out. The unreliable wireless link will cause the adaptive jitter buffer 
to select a large size for increased audio quality, but may be at a level 
with a larger delay than what is acceptable. Although Speex provides 
some configuration parameters to set the desired maximum latency, for 
testing purposes in the lEVAl radio system, it was more desirable to have 
a fixed, deterministic maximum allowed delay in the voice stream. As 
a result, the Speex / fVoIPI implementation in the lEVAl radio system does 
not utilize the built-in Speex adaptive jitter buffer provided by the Speex 
software library. The lEVAl radio system uses a fixed jitter buffer size, 
which is more deterministic and provides better control over the ob- 
served maximum delay in the voice stream than the adaptive technique. 
The fixed buffer size is appropriate for the initial lEVAl radio test setup, 
but other techniques should be considered for future development. In 
addition, Reference mi provides further insight into reducing the trans- 
mission delay for voice over multi-hop 802.11 wireless networks. Such 
techniques should also be considered for future development of the lEVAl 
radio system. 

3. 3. 3.1 Voice Data Distribution 

As already indicated, the voice data transmission builds upon IVoIPI 
technology. The encoded speech must be received by all the nodes, and is 
not simply a point-to-point IVoIPI stream. Each node in the wireless mesh 
must distribute the IVoIPl traffic to all of the other nodes on the mesh, as 
well as receive the IVoIPI traffic from the other nodes. In the lEVAl radio 
testbed, the IVoIPl audio stream is distributed using a multicast destina- 
tion address. All nodes in the mesh are then able to subscribe to the 
audio stream if the multicast packet is received. In a non lOLSRi enabled 
network, only the nodes with a direct link to the node broadcasting the 
multicast information would be able to receive the information. In the 
IQLSRl enabled network, an additional mechanism is necessary to dis- 
tribute the multicast data through the mobile ad hoc mesh, including 
nodes which may not have a direct connection to the originating node 
or to nodes which may have a limited connectivity. To handle the multi- 
cast data distribution and routing issue, the lEVAl radio system uses the 
Basic Multicast Forwarding (IBMFj) IOLSR I plug-in. The IBMFI module 
is designed to forward IP-multicast and IP-local-broadcast traffic over 
the network. The multicast forwarding is achieved by encapsulating the 
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original multicast packets and transporting them over a User Datagram 
Protocol (lUDPj) socket. The IBMFl module will relay and forward mul- 
ticast packets as necessary throughout the network. It is important to 
note that although the voice data is originally distributed using a mul- 
ticast address, the actual distribution throughout the network bv lOLSlil 
and the IBMFl plug-in is achieved in a unicast fashion. The unicast distri- 
bution of the multicast data is important because the wideband radio is 
configured to implement a fragmentation of the IWi-Fll frames. An 802.11 
source does not apply the fragmentation threshold setting to multicast 
or broadcast frames m- Thus, an additional advantage of utilizing the 
IOLSRIBMFI plug-in is that all of the multicast traffic will also be subject 
to the fragmentation threshold setting since all of the multicast data is 
relayed using a unicast link. 


3.3.4 Telemetry &: Sensor Data Distribution 

For distributing the sensor data throughout the network and for 
the internal Command and Data Handling (ICfeDHD subsystem on each 
node, the IEVAI radio svstem uses the BioNet framework m ■ BioNet is 
available as open-source code and provides plug-and-play operation of 
software/hardware. Control information and sensor data distribution is 
achieved through a publish and subscribe method with a service discov- 
ery protocol. BioNet can also provide a ICCSDSl compliant data delivery 
system by utilizing the Interplanetary Overlay Network (1IOND software 
package, which is also an implementation of the Delay-Tolerant Net- 
working (IDTNI) architecture [ll], [15]. The BioNet framework provides 
a standardized interface to software applications, and can be configured 
to either enable or disable the IDTNI capabilities as necessary without a 
direct impact on the software interface. 

For the IEVAI radio system, simulated telemetry data is collected from 
an on-board IGPSI unit. The positional telemetry is passed through the 
BioNet framework from each node on the IEVAI radio testbed to the base 
station node. In addition to the positional information, the simulated 
telemetry also includes sensor data from the switching algorithm and the 
IOLSR llETXI metrics from each node. The switching algorithm parame- 
ters, including the lETXl metrics, are distributed via BioNet throughout 
the entire mesh in addition to the base station node. The real-time 
voice data, as already described in Section 13.3.31 is not handled by the 
BioNet framework in the IEVAI radio testbed. This design choice is nec- 
essary, as real-time voice data must be received with a minimal amount 
of latency. A IDTNl enabled BioNet middleware could increase the data 
arrival latency by nature of the IDTNI store and forward architecture. 
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Figure 5. Test Setup for Simulated EVA Sortie. 


4 Experiment Test Description 

Performance testing of the lEVAl radio setup was performed in early 
September 2011 at the NASA 1 1 ) R AT Si outing. The tests were in the 
desert near Flagstaff, Arizona, which exhibits a terrain and environ- 
ment similar to a potential extraterrestrial exploration activities on the 
martian or lunar surface. For the IEVAI radio system tests, a scenario 
representative of an IEVAI sortie is executed which is also specifically de- 
signed to test two conditions pertinent to the lEVAl radio communications 
system: 

• Nominal Traverse 

• Hidden Node 

For the simulated IEVAI sortie, the test setup includes a remote ground 
station for visualization purposes, a stationary node and two remote mo- 
bile nodes. Figure [5] depicts the test configuration. The nominal traverse 
includes conditions with direct and non-direct line-of-site communication 
conditions on the high data-rate network to the base station via the sta- 
tionary node. The traverse path is designed such that the high data-rate 
communications link is established, lost, and then re-established. 

The classic hidden node condition is designed to generate a two-hop 
relay configuration for voice and data communications over the high data 
rate wireless network. One mobile node is positioned with a direct line- 
of-site communications link via the high-data rate wireless link to the 
base station and to the other mobile node. The other mobile nodes 
are positioned such that direct line-of-site data communication to the 
base station is not possible, yet a direct line-of-site link between the two 
mobile nodes is maintained. The scenario either requires communication 
via the 900 MHz contingency radio or for communication information to 
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(a) Rock Pile (Dest. No. 1) 



Figure 6. Destinations for Walk Test 


be relayed over the other remote node to the ground station. During 
the test, it is assumed that the contingency radio network is always 
accessible. 

4.1 EVA Test Scenario 

For the test scenario, two walking subjects representing I EVA I crew 
members are used for the mobile nodes. During the test, the subjects are 
to make notes and records of any interesting rock formations or sites of 
interest via video captures and audio transmissions. The test subjects are 
advised to maintain line-of-site distance to their companion walker and to 
conduct all conversations over the push-to-talk voice system, consistent 
with the characteristics of a normal fEVAl 

The test subjects are instructed to walk to two destinations of inter- 
est, simulating a geological science exploration lEVAl Destination No. 1 
is a volcanic rock pile near the base of SP Crater. Destination No. 2 
consists of a volcanic rock outcropping near a dry creek bed. A photo of 
the two test destinations is depicted in Figure El 

The actual traverse path taken by the walking crew members is not 
specifically marked. Yet, a large portion of the traverse route follows the 
dry creek bed, which passes by the base of SP Crater and connects to 
Destination No. 2. A topographical map of the testing area is depicted in 
Figure [TJ The test destinations are indicated in the figure and a potential 
walking path is also depicted. During the walking test, the subjects 
are led by a held guide between the destinations to ensure consistency 
between test runs. The held guide also ensures the held operations are 
efficient and safe, as the guide is already familiar with the test objectives 
and intended traverse path. The route led by the held guide is designed 
to always maintain connectivity on the low data-rate network, as the test 
is designed to evaluate the radio switching performance characteristics 
and not the ICOTSl radio hardware. 

To begin the test, the test subjects depart the base station location 
by descending down a slight hill to the dry creek bed. The test subjects 
then traverse from the base station to the rock pile (Destination No. 1) 
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Figure 7. Topo Map with Walk Test Destinations Near SP Crater. A 
dry creek bed runs between the rock pile and the rock outcropping at 
the base of SP Crater. 


by means of the dry creek bed. The route of the dry creek bed passes 
through locations where the direct line-of-site communication to the base 
station via the high data rate network is lost and then re-established. 
During this portion of the traverse, the IEVAI radio system will switch 
between the high data rate communications link and the contingency 
radio in order to maintain voice and data communications with the base 
station. Once at the first destination, one crew member moves to higher 
ground by carefully scaling the rock pile. This crew member maintains 
the high ground as the traverse is continued back along the dry creek 
bed. The crew members are instructed to always maintain line-of-site to 
each other during the traverse. The objective here is to generate a two- 
hop communications configuration for the lEVAl radio system. One crew 
member maintains direct line-of-site connectivity with the base station, 
while the other crew member following the dry creek bed. The path 
following the dry creek bed passes through regions where loss of direct 
connectivity occurs. At this point, the system may develop a two-hop 
data link configuration. If the health of the single direct link is not 
sufficient to maintain acceptable voice communications, the IEVAI radio 
system will switch to the contingency communications radio. 

After leaving the rock pile, the crew members rejoin in the dry creek 
bed and proceed to the second destination. Destination No. 2 is designed 
to break the direct line-of-site communications link for both of the EVA 
crew members to the base station. At this point, the system should tran- 
sition from the high data rate communications link to the contingency 
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Figure 8. Example Traverse Path. The traverse path for EV1 and EV2 
is depicted using cyan and magenta respectively. The base station tower 
is located at the Rover Vehicle. 


radio. After operating for some time on the contingency radio link, the 
test subjects then return up the hill back to the base station. Eventually 
the IEVAI radio system will switch back to the high data rate network as 
the link becomes available and stable link health metrics are observed. 

5 Early Assessment of Test Results 

5.1 System Evaluation 

The traverse path depicted in Figure [8] is representative of a route 
taken by the test subjects during the DRATS 2011 test experiments. 
The path demonstrates both the normal traverse and the hidden node 
(multi-hop) test conditions as described in Section [4j At the beginning 
of the traverse, both test subjects start from the Rover Vehicle and walk 
together to the rock pile. Once at the rock pile, one test subject, referred 
to here as EV1, ascends the rock pile to higher elevation. The other test 
subject, referred to here as EV2, stays within the confines of the dry 
creek bed and proceeds to the rock outcropping. Both EV1 and EV2 
maintain line-of-site to each other and join back in the dry creek bed 
prior to reaching the rock outcropping. For this particular traverse, EV2 
enters the rock outcropping, while EV1 stops short of the outcropping. 
After investigating the rock outcropping, both test subjects return to 
the Rover Vehicle. 
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Figure 9. ETX vs Time with Radio Switch Status. Shaded regions indi- 
cate radio switch periods on the low data rate network. An ETX value 
of one indicates a node in the network is missing. The region centered 
around the elapsed time of 3000 seconds on the high data rate network 
is a multi-hop route configuration. At this portion of the experiment, 
data for one test subject is routed through the other test subject back 
to the base station. 


5.1.1 Wireless Network Health Sensing &: Network Switching 

During the test, the lETXl value for all of the links is monitored and 
recorded by the IEVAI radio system. As the system switches between the 
two networks, the timestamp of the switch is recorded. The maximum 
recorded IETXI value for all of the 2.4 GHz radio links is used for driving 
the switching routines. Figure [9] shows the recorded IETXI value and the 
system behavior corresponding to the traverse depicted in Figure 0 The 
shaded regions of the plot indicate time spans where the IEVAI radio is 
utilizing the low data rate network. During the first portion of the tra- 
verse, with both test subjects walking together, the system maintains the 
high data rate radio connection. After an elapsed time of approximately 
550 seconds, the line-of-site connection to the base station is lost and the 
system switches to the low data rate network. This is observed in the plot 
by observing an lETXl value of one. A number of IETXI values above two 
are also observed, indicating an unreliable connection. The system then 
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regains connectivity using the IWi-Fil radio and switches from the low 
data rate network around an elapsed time of approximately 750 seconds. 

As the traverse continues, some fluctuation in the lETXl metric is ob- 
served, yet connectivity via the high data rate network is maintained. 
During some portions of the traverse, as EV1 maintains higher elevation 
and EV2 walks the dry creek bed at lower elevation, the system momen- 
tarily sets up a multi-hop scenario as fading of the connections causes 
one link to be preferred over another. Yet, the multi-hop condition is 
not maintained for a substantial amount of time. 

Near the end of the traverse with an elapsed time of approximately 
2700 seconds, as the test subjects approach the rock outcropping, the 
I EVA I radio system again transitions to the low data rate network. The 
data depicted in Figure [9] indicates that one of the nodes is missing from 
the network. The loss of connectivity via the IWi-Fil radio is achieved 
as EV2 enters the rock outcropping, while EV1 stops short of the out- 
cropping to perform a simulated science operation. At approximately 
an elapsed time of 2800 seconds, the system re-establishes a connection 
via the IWi-Fil radio. This region centered around 3000 seconds of elapsed 
time actually corresponds to a multi-hop condition over the 2.4 GHz net- 
work. The data for EV2 is relayed over EV1 to reach the base station. 

5.1.2 Voice Data Distribution 

Although user feedback provides a good representation of the system 
performance for distributing voice data between the nodes, a number 
of metrics may also be evaluated. The Speex audio packet arrival jit- 
ter provides an indication of the system voice characteristics. Figure [10] 
shows the observed Speex packet arrival jitter, which are typical and 
representative of the IDRATSl test runs. In order to ensure a continu- 
ous play of IRTPI voice data, the received Speex packets are buffered and 
the maximum jitter that can be accommodated is equal to the buffering 
delay. As indicated in Section 13.3.31 an end-to-end delay requirement 
of less than 200 ms is typical for IVoIPI applications and users tend to 
notice delays greater than 250 ms m, nu. As configured for these tests 
(refer to Section 13.3.31 Table |4j, the Speex packets contain 20 ms of voice 
data per Speex frame. A one-packet jitter therefore corresponds to an 
audio packet arrival time variation of 20 ms. As shown in Figure fTOl the 
maximum observed audio packet jitter is less than seven packets, corre- 
sponding to 140 ms of delay. Although the metric does not include the 
decoding time, the observed value is below the desired levels for an ac- 
ceptable two-way voice system. Further analysis of the total number of 
lost or late Speex packets indicates that the jitter buffer size could poten- 
tially be increased slightly to accommodate the observed jitter variation 
to improve voice quality during fade-outs in connectivity with a minimal 
impact on the end-to-end delay time. In addition, if the built-in Speex 
adaptive jitter buffer were utilized, the system would make use of the 
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Figure 10. Observed Maximum Audio Packet Jitter. Two representative 


data runs. Figure (a) corresponds to the traverse depicted in Figure El 


Figure [(b)] more clearly shows the difference in the observed jitter values 
between the two wireless networks during an extended period on the low 
data rate network. Shaded regions indicate radio switch periods on the 
low data rate network. 
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packets provided by the IDTXl option to catch up, by reducing the length 
between breaks in the voice data. 

The recorded maximum audio packet jitter values also show a de- 
pendency on the underlying wireless network used. In Figure [TU] the 
shaded regions indicate periods of time where the system is utilizing 
the 900 MHz communications radio. These timeframes exhibit a lower 
observed maximum audio packet jitter value than those periods when 
the 2.4 GHz radio is used. A number of factors could be attributed to 
this result. Indeed, slightly more data is being transmitted over the 
network when the wideband radio is in use, which could potentially gen- 
erate an increased delay in packet delivery. However, the increased data 
while on the 2.4 GHz wireless network is primarily due to video snap- 
shots, which are sent periodically in the form of hie transfers. The jitter 
data does not exhibit these periodic variations, suggesting the increased 
data how, although perhaps a contributor, is not the primary culprit 
for the increased jitter values on the wideband network. Instead, it is 
believed that the variation in the maximum jitter value between the two 
wireless networks is attributed to the underlying hardware and commu- 
nications parameters. For example, both a variable modulation scheme 
and a variable data rate setting are enabled on the 2.4 GHz radio. The 
900 MHz contingency radio is configured at a hxed data rate below the 
maximum data rate for the wideband radio. Yet, the lowest configurable 
data rate for the contingency radio is still above the lowest two data 
rates settings on the wideband radio when a variable modulation scheme 
is enabled. Thus, in areas with poor connectivity, the contingency ra- 
dio had a higher data rate than the wideband radio. In addition, the 
900 MHz contingency radio is more appropriately suited for the outdoor 
propagation environment than the wideband radio. The IGOTSI 900 MHz 
contingency radio is designed to be an outdoor access point, while the 
wideband radio is an indoor radio designed for use in an office environ- 
ment. The receive path design, especially the equalizer, is driven by the 
environment in which the radio will operate. Therefore, it is expected 
that the 900 MHz contingency radio will perform much better outdoors 
with regard to multipath effects. 

5. 1.2.1 Audio Packet Data Rate 

The Speex implementation in the lEVAl radio system is configured to 
utilize the IVADI and IDTXl features. The IVADI and IDTXl settings are 
beneficial, as the settings reduce the total number of bytes transmitted 
over the wireless connection. This feature is especially desirable for low 
bandwidth applications. The results clearly show a variation in the total 
data rate when the IVADI algorithms are enabled. Figure [TT] shows the 
results for the accumulated total number of transmitted audio bytes 
during a test run. During an extended period of silence observed near an 
elapsed time of approximately 1200 seconds in Figure fill a clear variation 
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Figure 11. Cumulative Transmitted Audio Bytes. A reduction in the 
transmit rate results from the Speex Voice Activity Detection (1VADI) 
and Discontinuous Transmission (1DTXI) mode. The effect is clearly seen 
for an extended period after an elapsed time of 1000 seconds. Shaded 
regions indicate radio switch periods on the low data rate network. 


in the total data rate is observed. The results indicate a potential benefit 
to wireless speech applications, especially when the data throughput rate 
may be constrained or highly variable. 

5.2 Test Subject Feedback 

At the IDRATSI outing, a number of test subjects were used for eval- 
uating the lEVAl radio technologies. The test subjects had a wide range 
of background experience including astronauts, flight controllers, scien- 
tists, engineers, and students. The test subjects provided subjective 
or personal perspectives on the IEVAI radio system and concept. These 
comments are summarized in the following sections. 

5.2.1 Voice Quality 

Overall the test subjects reported the voice transmissions were clear 
with excellent audio quality. One test subject indicated that the voice 
transmissions had a slight metallic sound which is believed to be at- 
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tributed to the small, low quality speakers and mounting strategy. H 
Other users did not note of any other discernible difference in the audio 
quality. The user feedback indicates that the Speex codec as configured 
is sufficient for audio transmissions from a speech intelligibility aspect. 
In addition, the Speex codec was configured for narrowband mode (8 kHz 
sampling rate) indicating that a higher quality signal is not necessary for 
the IEVAI radio application. 

During the IDRATSI experiment, a scenario was set up where one user 
did not have a direct link to the base station via the IWi-Fll link. but was 
able to receive voice communications over the IWi-Fil network using a 
multi-hop route. The users indicated that the data multi-hop setup on 
the IWi-Fil network worked well. The voice quality and throughput was 
maintained at an acceptable level. The users were quick to point out 
that a normal operational scenario would not utilize an astronaut for 
long periods to act as a “communications relay”. Still, the users agreed 
that the multi-hop option is a good capability to have for short durations 
and could be used to extend the lEVAl operational range. 

5.2.2 Switching Logic 

The test subjects provided feedback on the switching of the system 
between the two wireless networks. In general, the switching between 
the two wireless networks was seamless and provided good voice quality 
without interruption. The comments regarding the characteristics of the 
IEVAI radio switching related to the viewpoint of either the direct end 
user (astronaut) or the remote user (mission control). The astronaut just 
wants the audio to work and doesn’t care about the added capability that 
does not impact them directly. For instance, the astronaut is not going 
to be concerned if mission control is not receiving real-time high data 
rate video as long as the mission critical voice data flow is transmitted 
and the video eventually gets transmitted. As a result, the astronaut 
as an end user would prefer that the system switch immediately to the 
low data-rate communications link and be very slow to return to the 
more capable wideband network. The end user at mission control has 
the opposite desire, where they need as much remote data as possible 
and therefore would rather stay on the high data rate network as long as 
possible. Although some further tweaking of the switching algorithm is 
needed, it appears as though the current selected settings are reasonable. 

A number of users also indicated that it would be nice to have a 
switching override capability for contingencies. It is believed that this 
user feedback may have been generated by the very nature of how the ex- 
periment was conducted. For example, the end user was provided with 
audible tones every time the radio switched between networks. These 
audible tones were utilized to help system designers verify system func- 

2 The speakers were crudely mounted to the backpack frame by directly drilling 
through the speaker, which clearly modified the audio characteristics. 


N ASA/TM— 20 1 2-2 17635 


28 


tionality and to critique the system. The tones were also intended to 
help the end user identify the network being used when evaluating the 
quality of the voice provided by the communications subsystem. Under 
nominal operations, these audible tones would not necessarily be gener- 
ated and the switching between the networks would be transparent to 
the end user. These tones, however, made it immediately apparent as 
to the frequency of the switching between the networks, especially in an 
environment where a loss of or fading of the wireless communications 
link was common. Still, the capability to force the system to utilize one 
network or the other could be useful for a contingency scenario, provided 
that the manual override capability does not become a nominal opera- 
tional procedure. As a result, both mission control and the astronaut 
should have control over the manual override capability. In addition, the 
end user needs some sort of feedback, either visual or audible, to indicate 
the manual override is engaged. 

5.2.3 User Interface 

The user displays or human interface to the communications system 
was not a target development effort or an intended evaluation criteria 
for the IDRATSIIEVAI radio experiment. Still, the test subjects provided 
feedback on a desired user interface to the system. The users indicated 
a need for the health metric parameter conveyed to the user for each 
network. This is consistent with common-day mobile communications 
devices which indicate the number of bars for the wireless signal. During 
the experiment, the ground station terminal did indeed have a continuous 
feed for the health status of the wireless network for system evaluation 
and diagnostics. The health of the wireless network was conveyed to the 
user over the voice loops as desired or needed. During nominal opera- 
tions, it is not expected that the user would require a continuous update 
on the wireless network health status, but such information could be 
useful. For instance, real-time evaluation of the signal quality may allow 
the astronaut to select a different traverse path which would maintain 
better signal connectivity. The information may also be necessary in a 
contingency scenario. Regardless, the need for a health metric parameter 
indicator (i.e. , number of bars for each of the wireless communications 
networks) generates a requirement for basic status information to be 
provided from the communications system to the informatics system. 


6 Recommendations 

6.1 Environment Implications 

The IDRATSI experiment was performed in the Arizona desert and is 
a common test site for NASA analog studies. The location has histori- 
cally been used due to the similarity in terrain and conditions that may 
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be encountered at destinations beyond Earth. The landscape also has 
limited man-made structures and has applicable science to perform. In 
addition, for the lEVAl radio experiment, it presents a testing environment 
where the IRFI spectrum is relatively under-utilized compared to urban 
locations, with fewer concerns for interference with other spectrum users. 
Indeed this was case for the lEVAl radio team when conducting the exper- 
iment. There was only one other signal in the spectrum range of interest 
that needed to be avoided for possible interference. 

There were, however, some difficulties encountered during the testing 
that are attributed to the terrain at the Arizona test site. Debugging 
and diagnostic work on the IEVAI radio testbed indicated symptoms of 
a very high multipath environment. During one experiment, the orien- 
tation of the dipole antenna on the backpack was altered such that it 
was positioned at 90° to the source signal antenna. In this configura- 
tion, the radio signal strength increased and the IETXI metric improved. 
Such a response indicates the signal polarization had been altered or a 
reflected signal was stronger than the direct path signal. The test site 
landscape is free of man-made structures, which could be the source of 
large signal reflections and multipath effects as commonly encountered 
in an urban environment. The soil composition at the test site is primar- 
ily volcanic in nature and therefore contained a high iron concentration. 
This high iron concentration in the soil generated much higher multipath 
environment than anticipated. For the IEVAI radio testbed, the issue was 
handled by changing the radio configuration parameters. The [UHF] ra- 
dio utilized an IQFDMl modulation technique, which could be adjusted to 
provide better multipath rejection. In order to help cope with the mul- 
tipath environment, the IUHFI radio was configured to utilize a higher 
bandwidth at the same data rate. This in turn extended the symbol 
period to reduce the inter-symbol interference generated by the multi- 
path environment. By extending the symbol period, without reducing 
data rate, inter-symbol interference in a multipath environment is re- 
duced. Therefore, for further surface radio communication development 
efforts, consideration should be given to multipath effects in the radio 
design. There are a number of common solutions available for multipath 
mitigation and should therefore be considered for future design efforts. 
For example, spread spectrum techniques may be used to aid in reject- 
ing multipath effects or utilization of a rake receiver would enable the 
system to identify and compensate for multipath signals. 


6.2 Network Configuration Drivers 

6.2.1 Network Data Traffic Control 

During the IEVAI radio testing, it was determined that there is clearly 
a need for data queue prioritization of different network data types. 
There are a number of drivers for the data queue prioritization necessity. 
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For example, some data types, such as voice transmissions, must be deliv- 
ered with a low latency and in near real-time. Other data types, such as 
archived data, will have an increased allowable latency and does not nec- 
essarily need to be delivered in real-time. In addition, bandwidth-hungry 
network data, such as streaming high definition video, may swamp the 
entire allocated bandwidth. Thus, the network applications must be ca- 
pable of providing Quality of Service ( QoSD capability in order to provide 
different priority to different data flows. 

For the lEVAl radio testbed, the need for a |QoS| capability was recog- 
nized during evaluation of the health metrics for the wireless network. 
If the network becomes swamped with an application utilizing a large 
portion of the total available bandwidth, the IQLSRIlETXI metrics will 
become blocked or delayed and therefore will not accurately describe the 
health of the wireless links. Ideally, the IETXI metric will represent the 
quality of a route, independent of any network traffic. Indeed, De Couto 
recognizes this limitation in the IETXI implementation, indicating that 
“ |ETXj is highly sensitive to load because of the effects of unfairness 
and interference on the probe broadcasts” [6|. A suggestion to solve the 
issue is to implement a IMACI data communication protocol sub-layer, 
which supports priority traffic. The IQLSRIlETXI messages can then be 
isolated from the contending network traffic. 

Recognizing the need for QoS capabilities on wireless networks for 
multimedia applications, the [IEEE] 802. 11 standard was amended in 2007 

m 


to provide such |QoS| enhancements to wireless networks 


m- 


Yet, hardware that supports the QoS enhancements are not readily avail- 
able. As a result, an alternative method is implemented for the IEVAI 
radio testbed. The design uses the Linux traffic control El utilities for 
managing the transmission of packets [18]. Specifically, the lEVAl radio 
testbed uses tc commands to manage “traffic control”. Tc is a binary 
command line tool and is part of the iproute2 suite of utilities [19] . The 
application is used to manipulate network configuration structures in the 
Linux Kernel. Among many other uses, tc may be used to limit total 
bandwidth, prefer latency sensitive traffic, or to simply prioritize the 
data being sent to the network interface. For the lEVAl radio testbed, the 
system is set up to generate Kernel traffic control parameters to handle 
packet prioritization, rate limits and latency parameters. Yet, only the 
capability for network data prioritization was enabled for the IDRATSl 
experiments. The data prioritization is performed by establishing a pri- 
ority queue map. Priority levels are set as follows: 


1. BioNet traffic 

2. IOLSRI messages (control messages and IBMFl packets! 

3. IVoIPI audio packets 

4. All other network packets (not specifically prioritized) 

3 Quality of Service (|QoS|) is often used as synonym for traffic control. 
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Prioritization of BioNet traffic ensures that the radio switching algorithm 
has all the necessary information in order to perform the switch between 
radio networks. The BioNet packets handle the sensor data distribution 
throughout the network. Prioritization of the IQLSRI messages ensures 
that the network health statistics collected, or IETXI parameters, are 
representative of the underlying network. It is imperative that the IQLSRl 
broadcast messages are not delayed or blocked by other packets within 
the network. Finally, prioritization of the IVoIPl stream ensures that the 
voice traffic will always take precedence over any other traffic, especially 
resource-intensive traffic to help reduce the end-to-end latency. All other 
network traffic has a lower priority and is not specifically prioritized by 
the network configuration structures within the Linux Kernel. 


6.2.2 Wireless Link Access Time 


On the IEVAI radio system, the traffic originating from each node is 
prioritized to help ensure essential near real-time data is received in a 
timely manner. As discussed in Section [6.2.11 the network data |QoS] for 
the IEVAI radio testbed is regulated at each network device. Yet, fun- 
damentally, 802.11 is an access-driven network and not a time-driven 
network access; the 802.11 standard does not provide a means for limit- 
ing the access time of network nodes m- Thus, despite the IMACI layer 
data prioritization, the IEVAI radio system as designed with the 802.11- 
compliant ICQTSI radios still has the issue where low priority data may 
be delivered from one node before high priority data of another. For 
example, if a large file is being transferred over the network, it may pre- 
vent other nodes from transmitting any data for an extended period. The 
fragmentation configuration threshold does help to create more opportu- 
nities when another node may slip in a IRTSI request, but the setup does 
not guarantee that one node will not utilize all the available transmit 
time. The issue is further compounded when there is backlogged data, 
which may be the case if all the nodes are attempting to transmit data 
simultaneously. Thus, for an 802.11 IEVAI radio system, one needs to be 
able to limit the link access time, or to provide a preemption method for 
interrupting an existing link. A possible solution may be the 2007 |QoS 
enhancements to the HEEEl 802.11 standard. Future development efforts 
should evaluate the QoS enhancements as applicable to the IEVAI radio 
design. 


6.2.3 Network Packet Characterization 

The IQLSRI algorithm determines the network topology and the ex- 
pected transmission count in each direction of the link. For determining 
the probability of a packet being received at the destination, the IQLSR I 
IETXI algorithm assumes constant packet sizes in the network. The IETXI 
predictions may be adjusted to more appropriately reflect a particular 


N ASA/TM— 20 1 2-2 17635 


32 


Packet Type 

Payload Size 

[bytes] 

Notes 

Voice: 

Nominal 

115 

Speex IVoIPI data 

IVADl 

46 

“Silent Frames” 

IOLSRI 

HELLO 

44 - 48 


Eel 

76 - 108 

Variable. 


Table 5. Packet Sizes for OLSR and Voice Data in the EVA Radio 
System. The OLSR TC messages will increase in size as the number of 
nodes in the mesh is increased. Note that an entire TC message also 
includes HELLO message information. 


packet size |6] , but does not necessarily represent network traffic consist- 
ing of widely different packet sizes. When IOLSRI determines the IETXI 
metric, a different prediction error will be associated with different packet 
sizes 0. 

For the I EVA I radio system, the goal of the IQLSRIlETXI metric is to 
properly reflect the probability of voice data arriving at the destination. 
This information is used for the radio switching algorithm. Since the 
IQLSRI packets and the lVoIPl audio packets are similar in size, as shown in 
Tabled the [ETX] metrics accurately reflect the probability of a successful 
audio packet transmission. Therefore, when using IOLSRI link metrics 
for estimating the probability of a successful data transmission, some 
consideration for the associated packet size should be given. 

6.3 Delay Tolerant Networking Rationale 

In the initial stages of the I EVA I radio design, it was assumed that 
some sort of IDTNI implementation would be necessary for communicat- 
ing with the ground station. Yet it was quickly discovered that a IDTNI 
implementation of all the data flows was not necessary. IDTNI is designed 
for and excels well in communication links with long delays and with links 
having an approximate pre-determined range of expected transmission 
delay values. IDTNI is not designed for or intended to be used to handle 
communications links that are delayed due to the link fading in and out 
as opposed to just having a constant delay associated with the packet 
transmit time due to the distance between the transmitter and receiver. 
As a result, IDTNI need not necessarily be utilized for handling traffic 
flows between the nearly colocated nodes under nominal operations. For 
communications between space suits, the IDTNI implementation is not 
needed. To simplify the design, it would therefore make sense to imple- 
ment [DTN]only on a relay station that would be handling the potentially 
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long distance communications link to the ground station. 

The initial implementation of the I VoIP I communication on the lEVAl 
radio testbed was delivered using the IDTNl Bundle Protocol (1BPD . The 
IDTNIlBPl is designed to be a store-and- forward overlay network. The lBPI 
design is to help cope with intermittent connectivity and can take advan- 
tage of scheduled, predicted connectivity [20]. It was found difficult to 
implement IDTNl with data packets associated with voice communication 
information, such as IVoIPI traffic, due to the total latency added to the 
signal by the protocol and associated overhead. It is essential that the 
voice communication information be transmitted and delivered to the 
other nodes in the network with as minimal delay as possible. For IVoIPI 
applications, a delay requirement of less than 200 ms is typical nu. Dur- 
ing initial testing on the lEVAl radio testbed using the IBP! delays on the 
order of 250 ms could be achieved under ideal conditions, but it was not 
unusual to observe latencies on the order of a few seconds. In addition, 
if for some reason a disruption in the IRFI communication link occurs for 
a prolonged period of time, an individual typically would not want old 
voice data to be buffered up and transmitted. Instead, one would rather 
just drop the content. The newly generated or current near real-time 
voice communications data would take priority over any historical voice 
data. Historical voice communications data is therefore most likely only 
useful for individuals in the mission operations center for post-mission 
analysis. As a result, only certain nodes (primarily only the mission con- 
trol station) have a need or a use for real-time essential data, which is 
deemed to be stale or has been buffered up for a long time. 

Using a IDTNl implementation to transfer the IVoIPI traffic between 
all the nodes, especially between two space suits, is not practical. On 
the lEVAl radio system, the original IBPI implementation for the transfer 
of voice data was dropped in favor of a multicast IIJDPI connection. As 
noted, a IDTNl implementation would be desirable for transferring the 
data to a remotely-located ground station, but such a capability need 
not necessarily be implemented on the space suit. For the ground station 
link, one could provide those missing voice time segments as data files, 
which can be downloaded/received at later times for post-mission review 
and analysis. For the space suit data transfer portion of the link, the 
proper solution is likely a simple intelligent buffering system to handle 
the fade in/out of the wireless signal. 


7 Future Work 

7.1 System Configuration 

7.1.1 Switching Logic 

Prior to the IDRATSIIEVAl radio experiment, no effort had been de- 
voted to properly filtering the sensor data. The health metric for the 
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Figure 12. ETX Versus Time with Radio Switch Status, with Premature 
Switching. Shaded regions indicate radio switch periods on the low data 
rate network. Results indicate that filtering of the ETX values is needed. 



wireless metric, the lETXl value, is one such parameter that requires ad- 
ditional filtering. Some averaging of the IETXI value is built into the 
IOLSRJ software, but adjustment of the configuration parameters also af- 
fects the performance of the IOLSRI system. A second stage of filtering 
for use by the IEVAI radio switching logic is necessary to obtain the de- 
sired time-response characteristics. For system tuning of the IEVAI radio 
switching logic, some additional damping is desired. 

As indicated in Figure 01 the lETXl threshold for the switch from nar- 
rowband to the wideband radio is at a value of 1.8. In Figure fl2l the 
shaded regions indicate that the IEVAI radio is utilizing the low data rate 
communications link. A few of the transitions, for example at around 
an elapsed time of 1250 seconds and 3200 seconds, indicate that the sys- 
tem returned to the wideband communications link prior to the system 
achieving a stable IETXI value below the required threshold. After the 
transition, the IETXI instability shows values well above the set thresh- 
old of 1.8. The system does indeed eventually stabilize at an acceptable 
level below the 1.8 threshold, but a simple filter on the lETXl parameter 
for use in the switching logic would help to ensure the system does not 
prematurely switch to the wideband communications link. Future work 
should therefore include basic filtering of the network health metrics to 
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reduce switchovers from transients. 


7.1.2 OLSR Configuration 

The lETXl scheme of lOLSRl is not specifically intended to account for 
mobility of the underlying mesh nodes. In fact, Reference [6] questions 
if the lETXl metric would perform well in a mobile network. For the lEVAl 
radio testbed, the motion is slow compared to the update interval of the 
HELLO and ITCI messages. Care was taken to ensure the topology control 
and HELLO messages are updated at a rate faster than the system dy- 
namics. The motion of a person walking occurs at only modest speed of 
around 2 m/s, so it is possible to propagate the IQLSRl network metrics 
faster than the system dynamics. As a result, the lETXl metric can be 
applied to the mobile mesh consisting of walking people. Still, the config- 
uration values can be further modified to more accurately describe the 
underlying system. During the IDRATSl experiments, it was observed 
that the He] message interval most likely should have been modified. 
These observed characteristics may be an artifact of the environment 
due to the rate at which the radio signal is lost and re-established. To 
maintain consistency between the test runs, the parameters were kept at 
a fixed value throughout the IDR ATSl experiments. Future tests should 
consider increasing the update rate of the [TC] messages and perhaps re- 
ducing the corresponding validity time. In addition, future work with 
IQLSRf enabled mobile networks should consider inclusion of metrics pro- 
vided by the 802.11 interface card, such as the number of retransmissions 
per packet [Bj. During the lEVAl radio [DRATSI experiments, the num- 
ber of retry transmissions was logged. Unfortunately, the ICOTSIIWi-Fil 
device used in the testbed does not properly report the number of re- 
transmissions and appears to be unsupported by the driver. 

7.1.3 OLSR Multicast Configuration 

The forwarding mechanism for the IBMFl plug-in may be set to use ei- 
ther a “Broadcast” or a “UnicastPromiscuous” mode. The configuration 
of the lBMFl plug-in defaults to a “Broadcast” forwarding mechanism. On 
the lEVAl radio testbed, the parameter was not specifically set, resulting 
in the default configuration. According to the IBMFl documentation, the 
parameter most likely should have been set to “UnicastPromiscuous” for 
the wireless network [21] : 

“In the ‘UnicastPromiscuous’ mode, packets are forwarded 
(unicast) to the best candidate neighbor; other neighbors lis- 
ten promiscuously. IP-local broadcast is not used. This saves 
air time on 802.11 wireless networks, on which unicast pack- 
ets are usually sent at a much higher bit rate than broadcast 
packets (which are sent at a basic bit rate).” 
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The retransmission of the received packet is handled by the forwarding 
mechanism configuration parameter. Thus, for the I EVA I radio testbed, 
retransmissions were sent in a broadcast fashion. The IBMFI plug-in 
does send the original messages encapsulated into a IUDPI packet and 
are therefore delivered using unicast. Thus, multi-hop links may benefit 
from the “UnicastPromiscuous” setting for the IBMFI module. Although 
the communications links during the IEVAI radio tests were primarily 
direct, some performance increase may be achieved with the alternative 
configuration and should therefore be evaluated. 

7.1.4 Radio Configuration 

The wireless packet fragmentation threshold configuration setting for 
the IWi-Fll radio should be revisited in future lEYAI radio efforts. When 
fragmentation is enabled, the source network interface device divides the 
802.11 frames into smaller chunks or fragments. These fragments are 
sent separately to the destination, with each fragment receiving a sepa- 
rate acknowledgment. Fragmentation generates additional overhead and 
therefore decreases performance in an ideal environment. In a very noisy 
environment, the fragmentation threshold setting increases performance 
by allowing packets to get through interference bursts. The configura- 
tion value utilized on the IEVAI radio testbed was originally determined 
and verified in an urban environment. During the IDRATSI tests in the 
desert environment, verification of the fragmentation threshold value was 
not performed. Future work to determine an appropriate value for the 
expected environment should be performed. In addition, as already men- 
tioned in Section 18.3.31 802.11 does not apply fragmentation to multicast 
or broadcast frames [12]. Also, the IQLSTTI implementation encapsulates 
multicast information into unicast packets. Further work is necessary 
to properly characterize how fragmentation affects the link performance 
and the associated added network overhead for multicast messages dis- 
tributed by IOLSRI 

7.2 Localization 

The use of lOLSRl mav bring the additional benefit of localization in- 
formation or supplement position information systems. Indeed, a num- 
ber of individuals are attempting to use IOLSRI mesh connectivity in- 
formation to determine position information using convex optimization 
methods [22], [23]. These works attempt to estimate the unknown node 
positions for dense mesh networks. For sparse networks, such as the few 
node network expected for space exploration, additional information is 
likely necessary. Range information or time difference of arrival, for ex- 
ample, may be used with trilateration methods to determine position. 
Some research works utilize lOLSRI to distribute the routing and position 
information for simultaneous routing and localization [24] , [25] , [26] . Fu- 
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ture work should therefore consider the additional benefits IOLSRI may 
provide in terms of localization/position information. 

If position or velocity information is available, there are additional 
modifications to the IOLSR I implementation that may benefit a mobile 
mesh. As discussed in Section 13.3.11 IOLSRI needs to exchange the topol- 
ogy control information and receive the HELLO messages faster than the 
change in the layout of the mobile nodes in the mesh. This update 
rate must be increased for a highly mobile mesh. Yet, knowledge of 
the motion and the corresponding velocity could potentially be used to 
adaptively change the rate at which messages are transmitted between 
the nodes. Nodes which are in motion could send/receive HELLO mes- 
sages at a higher rate than those with a near stationary average velocity. 
An increased update rate for nodes that are in motion may improve the 
link characterization. Reducing the update rate for stationary nodes will 
also eliminate unnecessary packet transmissions and reduce the utilized 
bandwidth. Future work should evaluate the potential increase in perfor- 
mance achieved when positional information is used for variable IOLSR I 
packet update rates. 

7.3 Operational Concepts 

A number of operational concepts may be considered that are enabled 
by the multi-hop ad hoc mesh routing capabilities described in this work. 
These multi-hop scenarios may potentially extend the high data rate 
operational range. For example the “data mule” or remote relay concept 
could be envisioned. In one case, the multi-hop relay is achieved by a 
mobile node containing a store-and-forward capability. In the remote 
relay concept, a portable relay terminal or astronaut is used to relay 
both high data rate information and voice communications data. As 
already stated in Section 15.2.11 the use of an astronaut as a relay asset 
for extended periods is not likely. Yet, other operational concepts may 
be explored, such as for short durations or to “leap frog” across an area 
with limited connectivity. Furthermore, with the addition of portable 
communication terminals used for communications relay purposes, the 
fixed positional nature of these nodes could also aid the localization 
problem. 

7.4 Data Analysis 

During the IDRATSIIEVAl radio experiment, a number of parameters 
were collected for debugging, performance analysis and research pur- 
poses. Currently, only a preliminary data analysis has been performed 
on a small subset of the data collected during the experiment. Future 
efforts should be directed at a more complete data analysis. Refer to 
Appendix O for an explanation of the data collected during the experi- 
ment. 
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8 Concluding Remarks 


The IEVAI Radio Team designed and built a radio testbed that al- 
lowed for extensive field testing in Flagstaff, Arizona during the month of 
September 2011. The primary goal of this testing was to exercise the per- 
formance of the dual-band radio design, while operating in a simulated 
manned exploration environment. There were no major malfunctions or 
events that prevented the team from fully completing the full battery of 
tests over the two-week period. Multiple simulated exploration sorties 
were performed by both the team itself and objective subjects, including 
actual crew members from the astronaut corps. 

Each wireless interface comprising the lEVAl radio system individually 
worked well, even under these mobile test scenarios. External interfer- 
ence was never an issue, and the wireless coverage areas were consistent 
throughout the two- week period. The 802.11 ad hoc network proto- 
col performed quite well, even under the highly dynamic test scenarios, 
which included many forced network dropouts and hidden node situa- 
tions. The switching between the interfaces, guided bv IQLSRl generally 
worked well, but there were a few occasions when the hand-off between 
the interfaces produced a noticeable degradation in the voice quality just 
prior to a transition to the contingency radio. The team attributes this 
degradation to the switching algorithm, the [OLSR] configuration settings 
and the lack of filtering on the health metrics used for the switching al- 
gorithm. In general, the Speex audio quality was excellent, and several 
crew members commented that the voice quality was an upgrade to the 
existing IISSI radio system. 

The switching criteria used to trigger a jump of the lEVAl radio sys- 
tem from one interface to the other is the primary target for system 
improvement. The team used an appropriate set of IQLSRl link quality 
thresholds to trigger a switch, but several tests indicated these metrics 
were much more dynamic than originally expected. Several instances of 
“chattering” between the two interfaces were initially observed, which 
can be easily corrected by implementing standard sensor filtering tech- 
niques and by fine-tuning the IQLSRl configuration parameters. The data 
collected during the field tests will prove to be essential for establishing 
the system response characteristics for tuning these filters and for select- 
ing additional switching criteria. 

Although not an issue during the IDRATSl held tests, during sys- 
tem development efforts, the team had to experiment extensively with 
the 802.11 adapter software drivers. The software drivers are especially 
unpredictable when used in ad hoc mode. The team did generate a con- 
figuration suitable for the demonstrations, but this setup restricted the 
team’s ability to operate the 802.11 radios in several different modes of 
interest. A solution is to generate a set of in-house communication radios, 
in which the developers have complete insight and control. The use of 
custom radios for future tests would not only alleviate the driver issues, 
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but it would further allow incorporating physical network layer met- 
rics into the link switching criteria. Incorporation of the physical layer 
metrics, which are not typically available when using ICOTSI hardware, 
should improve the performance of the wireless interface link switcher 
algorithms. For example, physical layer hardware metrics may allow for 
a more accurate assessment of the link quality. 

In summary, this work has demonstrated a dual-band radio with in- 
telligent switching capabilities can effectively be used to achieve high 
data rates and extended operational range capabilities for mobile users. 
Simultaneous voice and data can be effectively transferred over the same 
limited bandwidth wireless connection and the IQLSRIlETXI metrics can 
be used as a metric for intelligent switching between two different capa- 
bility wireless mobile networks. 
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Appendix A 


Configuration Management 


Proper version control or configuration management is essential for 
any project utilizing software, regardless of the project size. Version 
control provides among many benefits a method for tracking and lock- 
ing changes and greatly enhances parallel concurrent development. The 
I EVA I radio development has utilized a complete configuration manage- 
ment system from the initial source code development through the actual 
software deployment. In order to fully appreciate the software develop- 
ment and deployment system implemented, some background knowledge 
is necessary. The IEVAI radio configuration management system consists 
of the following core technologies: 

• Version Control Server 

• Debian Source and Binary Packages 

• Debian Package Management System 

• Advanced Packaging Tool 

• Automated Builder 


A version control server is a system that manages changes to hies, main- 
tains current and previous hie revisions and allows collaborative modifi- 
cation of the same hies by a team of developers. A version control system 
typically provides the ability to revert to previous revisions, compare dif- 
ferences between revisions and may also merge different versions between 
multiple developers. Typically, a version control system is used to handle 
software source code, but is also readily applied to configuration hies and 
documentation. A number of open source systems exist. The lEVAl radio 
system utilized the Bazaar (1BZRI) distributed version control system. 

To promote modular software code development, each software dae- 
mon, library or conhguration parameters for the IEVAI radio system is 
distributed as a Debian package. A Debian source package is first cre- 
ated, from which a Debian binary package is then created for distribution 
to the desired hardware platform. A Debian binary package (.deb file) 
is simply a group of files, which is maintained as a single archive 


A1 


The package contains both the package data and the package metadata 
and installation/removal information [27] • The binary Debian package 
may contain for example the software executable (typically a compiled 
binary) and any documentation or configuration files. A Debian source 
package contains all the information necessary to build a binary package. 


A1 The archive file within a Debian package contains two tarball (.tar) files com- 
pressed with GNU zip utility, one containing the data and the other the corresponding 
control and configuration information for the package. 
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The source package consists of the original software source hies and the 
information required to build or compile the binary package. Although 
a binary package is the most typical and convenient to the majority of 
users, the source package format allows for a binary package to be cre- 
ated for a number of different operating system versions, architectures, 
or even compiled/linked against other different library versions. Thus, 
by starting first with a source package, the development method not only 
allows for complete flexibility and control over the deployed software, but 
additionally provides a further degree of version control and traceability, 
as the original software source used to create the binary package is also 
attached. 

Once the Debian packages are generated, the Debian Package Man- 
agement System, coupled with the Advanced Packaging Tool (IAPTD . is 
used for distribution and installation of the software. The Debian Pack- 
age Management System (dpkg) is a utility to install and remove soft- 
ware packages. The package management system automates the process 
of maintaining and installing software packages in a consistent manner. 
The system controls dependencies, conflicts and package versions. In 
addition, the system ensures proper installation and clean up from prior 
software package installations. IAPTI provides a front-end to dpkg with 
further networking enhancements, including the retrieval and installation 
of multiple Debian packages from a networked software package reposi- 
tory. For example, to install a hypothetical package called eva-example, 
one would issue the command apt-get install eva-example. The 
command instructs IAPTI to query the software repository and down- 
load the software package for automated installation by dpkg. In ad- 
dition, IAPTI also performs the retrieval of additional software packages 
from the networked software repository to satisfy package dependency re- 
quirements. During the installation process, if the package management 
system determines that additional software dependencies must also be 
installed, IAPTI searches the software repository for the dependencies and 
downloads the software packages as necessary for installation. The com- 
plete system allows for a complex system of modular software packages 
to be installed, maintained and versioned in a robust fashion. 

The final core technology utilized in the lEVAl radio software develop- 
ment flow is a networked automated builder. A networked software build 
server ensures that all deployed software packages are compiled against 
a consistent set of software libraries with a consistent set of development 
tools. Furthermore, an automated builder simplifies the build/test/de- 
ployment process as the entire procedure is extracted away from the soft- 
ware developer. The automated builder system may for example, auto- 
generate the Debian source package, compile the architecture-dependent 
binary Debian packages and then push the resulting packages to the 
IAPTI repository. For the IEVAI radio development, the open software 
project “Buildbot” is used by the entire development team. Buildbot 
is an open source “continuous integration system designed to automate 
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Automated Builder 



Figure Al. Software Development Flow 


the build/test cycle” [28]. A master buildbot builder triggers from com- 
mits to the software version control system. Automated builds are then 
distributed to a set of slave builders (either virtual or physical) for the 
desired set of processor architectures and operating systems. For the 
IEVAI radio development efforts, automated slave builders were setup for 
the i686 and x86-64 platforms to accommodate flexibility in development 
workstation and testbed platform hardware. 

The software development flow process for the IEVAI radio system is 
depicted in Figure IA1I In the software development process, the devel- 
oper first creates the desired software source files as is normally done with 
any software development effort. The software files are then submitted 
to a version control server for source code configuration management. 
The source project is then further modified by the developer to allow 
auto-generation of a Debian Source Package. In order to generate a 
Debian Source Package, a simple description file must be created, which 
describes the software package and necessary package build and run-time 
dependencies. In the Debian nomenclature, the package description in- 
formation is contained within a “debian/control” file. 

An example Debian Control file is shown in Listing [T] The first block 
describes the source package and the dependencies required to build the 
binary package. The second block describes the binary package gener- 
ated from the source package. A Debian source package may be used 
to generate multiple binary packages. In the example, a single binary 
package is listed and the corresponding required packages necessary for 
run-time are also listed. Within the Debian Control hie, a number of ad- 
ditional description fields may also be specified. The example provided 
only contains a minimal representative set of control fields. Further in- 
formation on the Debian package structure and additional control fields 
is available in References EH, Eg, m- 
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Source: eva-example 

Section : net 

Priority : extra 

Maintainer: Software Developer <nospam@NASA . gov> 

Build - Depends : debhelper (>= 7), cdbs , g + + , python 

Standards -Version : 3.8.3 

Package: eva-example 

Architecture : any 

Depends: ${ shl ibs : Depends } , ${misc : Depends } , 

python (> = 2.6) , python - daemon , net-tools , 
speex 

Description: Example software package for EVA. 

This is an example Debian software package for EVA. 


Listing 1. Example Debian Control File 


Appendix B 

Topographical Map Generation 


The topographical maps used in the ground station visualization pro- 
gram are generated using Digital Elevation Map (1DEMI) information 
available from the United States Geological Survey (IUSGSI) in GeoTIFF 
format. The topographical maps are only intended for visualization pur- 
poses and are not used for any portion of the algorithms implemented on 
the IE VAl radio testbed. Described here is the procedure used to generate 
the topographic map tiles used in the IEVAI radio visualization program. 

First, data is obtained from the IUSGSI The National Elevation 
Dataset (1NEDD 1/3 arc second data is downloaded by using the IUSGSI 
National Map Seamless Server Viewer at http://seamless.usgs.gov. 
The web interface allows INEDI information to be obtained for a rectan- 
gular area described by a set of latitude and longitude coordinates. To 
aid in automating the download process for multiple tiled regions, a cus- 
tom C^.net utility was created. The utility program GetUsgsDrats . exe 
takes as input parameters the latitude and longitude, the number of tiles 
to download and the desired size for each tile. These parameters are then 
passed to the Seamless Viewer to download each desired tile. 

Once the IDEMI information has been obtained, topographic contour 
lines and shading of the elevation levels is then generated into an image 
file. Post-processing of the IDEMI fi les is obtained by using the open 

which is a front-end interface to 


source Mirone 


software too’ 


B1 


the open source Geospatial Data Abstraction Library (1GDALI) . Using 
Mirone, the GeoTIFF files are used to generate contours for all of the 


B1 Mirone may be obtained from http://w3.ualg.pt/~jluis/mirone 
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tiled images at regular-spaced intervals and to generate a color shading 
between the minimum and maximum elevation observed in the entire 
set of downloaded tiles. Using Mirone, a set of image files are generated 
which are representative of topographic information. The open source 
ImageMagicM B2 l suite of utilities is then used to aid in cropping and re- 


sizing the resolution of the Mirone-generated image hies. 


B.l Detailed Instructions 

An abbreviated step-by-step set of instructions for generating the 
topographic tile images is presented as follows: 

1. Download IIJSGSIlDEMI hies using GetUsgsDrats . exe 

(a) Enter latitude/longitude, tile size and number of tiles. 

(b) Start the program and select Download to save .zip hie. 

(c) Click Next to repeat the process. 

2. Extract downloaded .zip hies. 

3. Start the Mirone software tool. 

(a) Open the extracted GeoTIFF hies. 

(b) For each downloaded GeoTIFF hie, note the maximum/min- 
imum elevation to determine the limits for the given set of 
tiles. Grid Tools — Contours — Contour Tool. 

(c) Return to TIFF hies, and for each: 

i. Select Palette TB. Enter the maximum/minimum eleva- 
tion values for the set to make color gradients consistent 
throughout the entire set of tiles. 

ii. Select Image — Illuminate — GMT GrdGradient. Ac- 
cept the default values. 

iii. Select Grid Tools — Contours — Contour Tool. 

iv. Select Add Common Charting Intervals. Add any other 
desired contour elevation value by typing in value in Sin- 
gle input form held. 

v. Select Apply. 

vi. Select File — Export. And save image as .png at the 
maximum available resolution. 

(d) Use ImageMagick to remove scale area from tiles: 

convert -crop 6935x7271+490+73 INPUT. png OUTPUT. PNG 

(e) Rename the images hies to the format: 
USGS_LAT_LON_LAT-SPAN_LONG-SPAN_. PNG 

where the latitude and longitude are for the center of the tile. 

B2 ImageMagick is available from http://www.imagemagick.org 
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Note that the custom utility program RenamePngs . exe will 
aid in the file renaming process. 

(f) Use ImageMagick to scale the image files to desired size: 

convert -scale 25% USGS_xxx.PNG USGS_yyy.PNG 


N ASA/TM— 20 1 2-2 17635 


46 


Appendix C 


Experimental Data Description 


During operation of the lEVAl radio testbed, a number of parameters 
and sensor data is collected to aid in system development and perfor- 
mance analysis. A brief description of the data collected and file formats 
is described here. 

In general, file names are of format TYPE_timestamp.ext. The times- 
tamp format is in POSIX time, or the number of elapsed seconds since 
epoch, 01 Jan. 1970. The timestamp is from the system time on the 
device which the data was recorded. The system time of all the nodes 
were synchronized at the start of the IDRATSI 2011 outing via network 
time protocol, but were left free-running without updates throughout the 
duration of all the tests. The offset in the system time can be determined 
from thc lGPSl log files, where both the system time and the time derived 
from IGPSI is recorded. The file extension may be either . bin for raw 
binary, or representative of the contents such as .csv for comma sepa- 
rated values or .mp4 for encoded video or . spx for Speex encoded audio. 
All text files contain a header to indicate the format of the data within 
the log file. All binary format files adhere to standardized formats. 

Audio Data Files of type AUDIO contain Speex-encoded audio data as 
it was received at the destination node. Playback of these files allows a 
user to hear the audio as it was played to the test subject via the external 
speakers during the system test. 

Configuration Files Any of the configuration files that may have 
been altered prior to a test are copied for documentation purposes. The 
configuration files help to confirm settings utilized on a particular run. 
The configuration files include parameters pertaining to the audio encod- 
ing, the link switcher settings, the IQLSRl configuration, and the network 
interface configuration. 

Position Data Files of type NMEA contain the raw IGPSl data in INMEAl 
format as transmitted by the IGPSl everv second. Files of type GPS contain 
an extracted set of positional information which was distributed across 
the wireless network to the base station. 

OLSR Data Files of type 0LSR_D0Tx has output from the IQLSRl dae- 
mon. This data is the raw [OLSR] output from a text plug-in and contains 
information on the network topology and the forward and neighbor link 
quality from which the lETXl metrics are derived. The information in this 
file is parsed and then extracted to generate network health information 
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to be used by the link switcher algorithm. Files of type OLSR_SWITCH 
contain the parsed IOLSRI information and is the information which is 
distributed throughout the network for use by the link switcher algo- 
rithm on each node. 

Radio Connectivity Information A number of data file log types 
exist for determining the radio and network connectivity information. 
Logs pertaining to radio connectivity and health information are found 
in files of type: IFCONFIG, IWCONFIG, SNMP_IFCONFIG and SNMP_RSSI. 
The IFCONFIG and IWCONFIG file types pertain to the 2.4 GHz radio. 
These logs contain information as generated by the Unix ifconf ig and 
iwconfig commands. The SNMP_X hie types pertain to the 900 MHz 
radio. These logs contain information similar to that generated by the 
Unix ifconfig and iwconfig commands. 

Raw Network Traffic Files of type TCPDUMP contain all of the raw 
network data which was sent over the network interface. The data hies 
are generated with the tcpdump utility and may be read using libpcap 
capable utilities such as wireshark. The data hies contain a .bin ex- 
tension to indicate they are of a binary format. 

Switching Algorithm Status Files of type SWITCH and SWITCH_ETX 

contain information from the switching algorithm. Each time a switch 
between the high data rate and low data rate networks is performed, 
a timestamp and status information is logged to the SWITCH hie. The 
SWITCH_ETX hie type contains the network IETXI information which the 
switching algorithm uses on each cycle of the routine. 

Video Files Files of type VIDEO are MPEG-4 video hies as recorded on 
the mobile nodes. The video hies are approximately 10-second snapshots. 
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Appendix D 


Acronyms and Abbreviations 


AP Access Point 
APT Advanced Packaging Tool 
AEC Acoustic Echo Cancellation 
BER Bit Error Rate 
BZR Bazaar 

BMF Basic Multicast Forwarding 

BP Bundle Protocol 

BPSK Binary Phase Shift Keying 

CCSDS Consultative Committee for Space Data Systems 

COTS Commercial Off-The-Shelf 

CTS Clear To Send 

C&DH Command and Data Handling 

DRATS Desert Research and Technology Studies 

DTN Delay-Tolerant Networking 

DTX Discontinuous Transmission 

DEM Digital Elevation Map 

ETX Expected Transmission Count 

EVA Extravehicular Activity 

GDAL Geospatial Data Abstraction Library 

GPP General Purpose Processor 

GPS Global Positioning System 

GRC Glenn Research Center 

IEEE Institute of Electrical and Electronics Engineers 

ION Interplanetary Overlay Network 

ISM Industrial, Science and Medical 

ISS International Space Station 

ITU International Telecommunication Union 

IP Internet Protocol 

MAC Media Access Control 

NASA National Aeronautics and Space Administration 
NEA Near-Earth Asteroid 
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NED National Elevation Dataset 

NMEA National Marine Electronics Association 

OLSR Optimal Link State Routing 

OFDM Orthogonal Frequency-Division Multiplexing 

PAS Power, Avionics, and Software 

QoS Quality of Service 

RF Radio Frequency 

RTP Real-time Transport Protocol 

RTS Request To Send 

TC Topology Control 

UDP User Datagram Protocol 

UHF Ultra High Frequency 

USGS United States Geological Survey 

VAD Voice Activity Detection 

VoIP Voice over Internet Protocol 

Wi-Fi Wireless Fidelity (IEEE 802.11 wireless networking) 
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